REMARKS 

In the Office Action, the textual portion of the specification was objected to as 
being replete with grammatical and idiomatic errors. Claims 4 and 8 were also objected 
to for various informalities. The Office Action also rejected the pending claims as 
follows. Claims K 5, 6, 8, 9, 10 and 18-21 were rejected under 35 U.S.C § 112. second 
paragraph, as being indefinite for failing to particularly point out and distinctly claim the 
subject matter which applicant regards as the invention; and Claims 1-21 were rejected 
under 35 U.S.C. § 102(e) as being anticipated by U.S. Patent No. 6,684.081 to 
Sarkkinen et al. 

The Specification, the Abstract and Claims 1-10, 1 1-17 and 20 have been 
amended. Claims 18, 19 and 21 have been cancelled. No new matter is presented. 

In response to the rejections under 35 U.S.C. § 1 12, second paragraph, the 
amendments to the Specification and claims 

Sarkkinen et al. is cited in the Office Action as anticipating each pending claim. 
An anticipation rejection requires that a single cited reference disclose each and every 
recitation of each rejected claim. For at least the following reasons, the rejection must 
be withdrawn. 

In regard to Claim 1, the Examiner states that Sarkkinen et al. allegedly discloses 
a service announcement message that includes "sending times and sending time duration 
as parameters. v (Office Action, page 6.) However, neither the cited portion nor 
elsewhere does Sarkkinen et al. include such disclosure, and Sarkkinen et al. fails to 
disclose or suggest at least the recitation of wherein said request includes sending times 
and sending time duration as parameters of Claim 1 . 
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In regard to Claim 10, the Examiner cites Sarkkinen et ah as allegedly disclosing 
a ITRAN that "arranges time for scheduling." (Office Action, page 15.) However, 
neither the cited portion nor elsewhere does Sarkkinen et al. include such disclosure, and 
Sarkkinen et ah fails to disclose of suggest at least the recitation of arranging by the 
UTRAN of a sending time of a MBMS notification message. 

The Examiner further states that "Claim 15 has similar limitations of Claim 10" 
and rejected Claim 1 5 "under the same rationale as in Claim 10 above." (Office Action, 
page 1 8. ) Accordingly, for at least the above reason, the rejection of Claim 1 5 must be 
withdrawn. 

In regard to Claim 20, the Examiner cites Sarkkinen et al. as allegedly disclosing 
UTRAN "and the apparatuses in core network co-establish network resources." (Office 
Action, page 21.) However, contrary to an alleged co-establishing, the invention of 
C laim 20 co-releases network resources, which is not disclosed in Sarkkinen et al. 
For at least the above reasons, it is respectftilly submitted that all pending 
claims herein, namely Claims 1-17 and 20, are in condition for allowance. Should the 
Examiner believe that a telephone conference or personal interview would facilitate 
resolution of any remaining matters, it is requested that the Examiner contact 
Applicant's attorney at the below number. 



Respectfully submitted, 



THE FARRELL LAW FIRM 




333 Earle Ovington Boulevard, Suite 701 
Uniondale. New York 11553 
Tel 516-228-3565 



Reg. No. 51,314 
Attorney for Applicant(s) 
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tteto g Cell Broadcast for MBMS Service Announcement -and 
Notification USING CELL BROADCAST FOR MBMS SERVICE 
ANNOUNCEMENT AND NOTIFICATION 



5 PRIORITY 

This application claims priority to an application filed in the Chinese 
Industrial Property Office on August 15. 2002. assigned Serial No. 02130506.4. 
as well as to application PCT/KR03/01648 filed August 14. 2003. the contents of 
which are incorporated herein by reference. 

10 

Background of the invention 



1. Field of invention 



15 The present invention relates to a method for sending and receiving 

Multimedia Broadcast/Multicast Service (MBMS) data in communication 
system, especially to a method of sending and receiving S e rvio e service 
announcement Announo e m e nt -and S e rvic e service n otification in Multimedia 
Broadcast/Multicast Service with the aid of using cell broadcast. 

20 

2. Description of the p rior art 
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Multimedia Broadcast/Multicast Service (hereinafter referred to as 
MBMS) is a new service under standardization by 3 rd Generation Partnership 
Project (hereinafter referred to as 3GPP). The standard being developed is 
TS23.846, whose latest version is 1.1.1. MBMS service is a unidirectional 
5 point-to-multipoint (p-t-m) service, whose most remarkable characteristic is that 
it can make use of radio resources and network resources efficiently. 



A system structure of MBMS is described in the following with 
reference to Figure 1. As shown in Figure 1, the MBMS network structure is 

10 based on the core network of General Packet Radio Service (hereinafter referred 
to as GPRS), and further adds new network elements. Broadcast and multicast 
service center 101 (hereinafter referred to as BM-SC) is the service control 
center of MBMS system. Gateway GPRS Supporting Node 102 (hereinafter 
referred to as GGSN) and Service GPRS Supporting Node 103 (hereinafter 

15 referred to as SGSN) compose the transmission network of MBMS service and 
provide route -routing for the transmission of data. Home Location Register 106 
(hereinafter referred to as HLR) stores the data related to auser and can provide 
services such as user's authentication. Universal Mobile Telecommunication 
System ( UMTS) Terrestrial Radio Access Network 104 (hereinafter referred to 

20 as UTRAN) provides radio resources for MBMS service over the air-interface* 
Uul07 indicates a radio interface between terminal and access network. User 
Equipment 105 (hereinafter referred to as UE) is a terminal device for receiving 
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data. Cell Broadcast Center 108 (hereinafter referred to as CBC) is a data source 
of cell broadcast. Radio resources used by MBMS service are not dedicated for 
one user, but are shared by all users using this service. 

5 A MBMS multicast service flow is described in the following with 

reference to Figure 2. As shown in Figure 2, the MBMS multicast service flow 
includes the following steps: 

In-SGOr.Subscription step r 200 establishes the relationship between user 
10 and service provider, which allows the user to receive the related MBMS 
multicast service. 

In 201, Service announcement step ? 201 informs UEs about the types 
and service areas of forthcoming multicast services. 

15 

In 202, J oining step ? 202 is the process by which a subscriber joins a 
multicast group, i.e. the user registers the network in which the MBMS multicast 
service types that he is willing to receive. 

20 In 203, MBMS multicast mode bearer set up ste p 203i establishes the 

network resources for MBMS multicast data transfer 
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In 204, MBMS notification step i 204 informs UEs about forthcoming 
MBMS multicast data transfer. 

In 205, Data transfer step i 205 indicates the phase when MBMS 
5 multicast service data are transferred from the network to the UEs. 

In 206, M BMS multicast mode bearer release step 206? indicates to 
release the network resources after MBMS service data transfer finishes. 

10 In 207, L eaving step 207. corresponding to 202 joining step, indicates 

that a subscriber is leaving a service group, i.e. the user no longer wants to 
receive Multicast mode data of a specific service. 

The necessary flow of providing a MBMS broadcast service is described 
15 with reference to Figure 3. As shown in Figure 3, the MBMS broadcast service 
flow includes the flowing steps: 

^OO^Service announcement ste p 300 , which i nforms UEs about the types and 
service areas of forthcoming services. 

20 3&h-MBMS broadcast mode bearer setup ste p 301. which establishes 

the network resources for MBMS broadcast data transfer. 
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3Q3rMBMS notification ste p 302. which informs the UEs about the forthcoming 
MBMS broadcast data transfer. 

303, D ata transfer step 303. which indicates the phase when MBMS 
5 broadcast data are transferred from the network to the UEs. 

304t-MBMS broadcast mode bearer release ste p 304 . which indicates to 
release the network resources after MBMS broadcast service data transfer 
finishes. 

10 

In the MBMS Multicast service flow shown in Figure 2, the operation in 
step 200, 201 and 202 should be performed for different UEs respectively, and 
remaining steps are performed by all UEs in the same type of service. The series 
of steps can be performed repeatedly, and step 200, 201, 203, 204 or 207 can be 
1 5 performed in parallel with other steps. 

In the MBMS broadcast service flow shown in Figure 3, this series of 
steps can be performed repeatedly and step 300 and 302 can be performed in 
parallel with other steps. 

20 

A €eH- cgJj broadcast Broadcast indicates to transfer data transfer b y 
using a common service channel in a cell so as to enable all UEs staying in the 
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cell capable of receiving the broadcast data of the cell. Refer to 3GPP standard 
TS25.324 (the latest version is 5,1.0) for the description of cell 
Broadcast/Multicast Control module BMC. 

5 But in the steps shown in Figure 2 and 3, in-existing standard TS23.846? 

it-only mentions m entioned that Servioe service announcement steps can be 
completed by CBC, but the implementation method hasn't been given, and 
didft^f-no mention is made of w kh-what devices and how to implement MBMS 
Service notification steps, whieh -making m ake-it impossible to completely 
10 implement MBMS multicast service flow and MBMS broadcast service flow. 

SUMMARY OF THE INVENTION 

Therefore, an object of the present invention is to provide a method on 
15 how to use a cell broadcast to realize MBMS service announcement and MBMS 
service notification so as to make MBMS service be a complete flow. It is noted 
that the Cell Broadcast herein indicates a method of transmitting data via a 
common service channel over a air-interface of the cell, and it does not relates to 
specific devices such as CBC. When the cell broadcast is used to support the 
20 MBMS service announcement or MBMS service notification, messages sent 
from CBC and SGSN can all be sent out through cell broadcast. 



Patent Application No. 10/524.715 
Substitute Specification 
Docket: 678-1881- 1— 



According to one aspect of the present invention, a process of a UE 
receiving MBMS multicast service data is shown in Figure 4, and includes the 
following steps: 

5 4Q9r-Subscription step ? 400 indicates a process of the UE subscribing a 

specific type of MBMS service, which makes the UE establishing relationship 
with the specific type of MBMS and be authorized to receive this specific type 
of MBMS service in the future; 

10 404,-Service announcement step ; 401 indicates a process of the UE 

being informed of the MBMS multicast service types and relevant parameters by 
receiving the service announcement information included in cell broadcast; 

402r- Joining step ? 402 indicates a process of the UE joining the specific 
15 MBMS service multicast group, which corresponds to the MBMS service one to 
one, the multicast group including all subscribers who receive the MBMS 
service; 

403T-MBMS Service notification step_403 ? indicates that the UE is 
20 informed that the MBMS multicast service data, which is expected to receive by 
the UE, is forthcoming, by receiving MBMS Service notification information 
included in cell broadcast; 
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404r- Data transfer step ? 404 indicates a process of the UE receiving the 
MBMS service multicast data; 

Leaving step i 405 indicates a process of the UE leaving the specific 
MBMS service multicast group that it is used to join. 

SA process of a UTRAN sending the MBMS multicast service data is 
shown in Figure 5, and includes the following steps: 

#005— Service announcement ste p 500? indicates that the UTRAN sends 
information on MBMS service types and service areas via cell broadcast; 

504-j-MBMS multicast mode bearer set up step ? 501 indicates a process of co- 
establishing the network resources for the MBMS service by the UTRAN and a 
core network; 

§02r-MBMS service notification step ? 502 indicates that the UTRAN sends a 
MBMS service notification message via cell broadcast, the message indicating a 
forthcoming of a specific MBMS service data, and making all users of this 
multicast group prepare radio resources; 
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503. data Data transfer step ; 503 indicates that the UTRAN sends a real MBMS 
service data; 

§04r-MBMS multicast mode bearer release step 504 ; indicates that after the 
transfer of the MBMS service data being completed, the UTRAN and other 
devices in the core network co-release the network resources for the MBMS 
multicast service. 

■OA process of the UE receiving the MBMS broadcast service data is 
shown in Figure 6, and includes the following steps: 

60©r-Service announcement step ; 600 indicates a process of the UE being 
informed of the MBMS broadcast service types and relevant parameters by 
receiving the service announcement information included in the cell broadcast; 

6QVMI3MS service notification step ? 601 indicates that the UE is informed that 
the MBMS broadcast service data, which is expected to receive by the UE, is 
forthcoming, by receiving MBMS service notification information included in 
cell broadcast; 

603r-Data transfer step 603 indicates a process of the UE receiving the MBMS 
broadcast service data; 
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SA process of the UTRAN sending the MBMS broadcast service is 
shown in Figure 7,and includes the following steps: 

5 700_Service announcement step ; 700 indicates that the UTRAN sends 
information on MBMS service types and service areas via cell broadcast; 

?©VMBMS broadcast mode bearer setup step 70 U indicates a process of co- 
establishing the network resources for the MBMS broadcast service by the 
10 UTRAN and the core network; 

702j-MBMS service notification step ; 702 indicates that the UTRAN sends a 
MBMS service notification message via cell broadcast, the message indicating a 
forthcoming of a specific MBMS service data, and making all users of this 
1 5 multicast group prepare radio resources; 

703. data D ata t ransfer step ; 703. indicates that the UTRAN sends a real MBMS 
service data; 

20 704r-MBMS broadcast mode bearer release step ; 704 indicates that after the 
transfer of the MBMS service data being completed, the UTRAN and other 
devices in the core network co-release the network resources for the MBMS 
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broadcast service. 



According to another aspect of the present invention, the method for 
transferring service announcement of Multimedia Broadcast/Multicast Service 
5 (MBMS) includes the following steps: 



(a) Broadcast/Multicast Service Center (BM_SC) requests Cell Broadcast Center 
(CBC) to send a service announcement by a signaling message in a Multimedia 
Broadcast/Multicast Service (MBMS) service area, wherein said request can 
1 0 include sending times and sending time duration as parameters; 



(b) After receiving the signaling message from BM_SC, Cell Broadcast Center 
(CBC) commands UMTS Terrestrial Radio Access Network (UTRAN) 
connected with it to send the service announcement through the signaling 

15 message; 

(c) UMTS Terrestrial Radio Access Network (UTRAN) arranges the sending of 
Multimedia Broadcast/Multicast Service (MBMS) service announcement 
message in a prescribed time of one or more schedule periods according to the 

20 requirement of Cell Broadcast Center (CBC), adds brief description information 
to a schedule message for describing each schedule period and sends the 
schedule message; after receiving the schedule message, UE analyzes the 
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schedule message and then configures its physical layer to prepare for receiving 
the Multimedia Broadcast/Multicast Service (MBMS) service announcement 
message; and 

5 (d) UMTS Terrestrial Radio Access Network (UTRAN) sends Multimedia 
Broadcast/Multicast Service (MBMS) service announcement message at the 
prescribed time^r 

Wwherein the transfer times in the step (a) can be a plurality of times or infinite 
10 times. 

In addition, after UMTS Terrestrial Radio Access Network (UTRAN) 
completes the sending of the Multimedia Broadcast/Multicast Service (MBMS) 
service announcement message, it may send confirmation information to Cell 
15 Broadcast Center (CBC). After receiving the confirmation information from 
UTRAN, Cell Broadcast Center (CBC) returns confirmation information to 
BM_SC subsequently. 

In the above step (b), according to the requirement of BM_SC, Cell 
20 Broadcast Center (CBC) can require UMTS Terrestrial Radio Access Network 
(UTRAN) to send the service announcement periodically a plurality of times or 
infinite times. 
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In the above step (d), UMTS Terrestrial Radio Access Network 
(UTRAN) sends the Multimedia Broadcast/Multicast Service (MBMS) service 
announcement message a plurality of times according to the requirement of Cell 
5 Broadcast Center (CBC), and the step (c) and (d) can be repeated a plurality of 
times without a certain precedence order. 

In addition, the service announcement message includes parameters of 
the Multimedia Broadcast/Multicast Service (MBMS) service types and service 
10 areas. 

According to another aspect of the present invention, the method for 
transferring a Multimedia Broadcast/Multicast Service (MBMS) service 
notification includes the following steps: 

15 

(a) BM_SC sends the Multimedia Broadcast/Multicast Service (MBMS) data to 
GGSN; 

(b) After receiving said data sent by BM_SC, GGSN sends said data to SGSN by 
20 tunneling technique; 

(c) After receiving the signals from GGSN, SGSN informs UMTS Terrestrial 
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Radio Access Network (UTRAN) of the forthcoming of the Multimedia 
Broadcast/Multicast Service (MBMS) data via a signaling message; 



(d) Radio data Access Bearer (RAB) is established between UMTS Terrestrial 
5 Radio Access Network (UTRAN) and SGSN; 



(e) SGSN sends the Multimedia Broadcast/Multicast Service (MBMS) data to 
UMTS Terrestrial Radio Access Network (UTRAN) via Radio data Access 
Bearer RAB; 

10 

(f) After receiving the described data from SGSN, UMTS Terrestrial Radio 
Access Network (UTRAN) arranges the sending time of a Multimedia 
Broadcast/Multicast Service (MBMS) service notification message, which 
includes to arrange sending at the prescribed time of one or more schedule 

15 periods, and to add a brief description information to the schedule message for 
describing each schedule period and to send the schedule message. After 
receiving the schedule message, UE analyzes the schedule message and 
configures its physical layer to prepare for receiving the Multimedia 
Broadcast/Multicast Service (MBMS) service notification message; 

20 

(g) UMTS Terrestrial Radio Access Network (UTRAN) sends the Multimedia 
Broadcast/Multicast Service (MBMS) service notification message at the 
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prescribed time; 

(h) UE requests UTRAN to allocate Radio Bearer (RB) via a signaling message, 
and a plurality of UEs can send requests to UMTS Terrestrial Radio Access 

5 Network (UTRAN) simultaneously; 

(i) UMTS Terrestrial Radio Access Network (UTRAN) allocates the radio bearer 
(RB) according to the number of UEs and other comprehensive factors, and 
informs the UE; 

10 

(j) UMTS Terrestrial Radio Access Network (UTRAN) sends the Multimedia 
Broadcast/Multicast Service (MBMS) data to the UE via RB. 

The above step (e), step (f) and step (g) can be performed without a 
15 certain precedence order. 

The data transfer flow of MBMS broadcast service is similar with that of 
multicast service, except that it does not need the step (h), and in the step (i), 
UMTS Terrestrial Radio Access Network (UTRAN) allocates radio data bearer 
20 (RB) according to comprehensive factors without consideration of the number of 
UEs. 
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The step of UMTS Terrestrial Radio Access Network (UTRAN) sending 
a service notification or a service announcement message of Multimedia 
Broadcast/Multicast Service (MBMS) data via cell broadcast further includes the 
following steps: 

5 

(1) Multimedia Broadcast/Multicast Service Control Module (MBMSC) receives 
a signaling message sent from the core network nodes (SGSN, CBC), which 
informs UMTS Terrestrial Radio Access Network (UTRAN) to send a service 
announcement message or service notification message of Multimedia 

10 Broadcast/Multicast Service (MBMS) and includes the necessary parameters for 
constructing the service announcement message or service notification message 
of Multimedia Broadcast/Multicast Service (MBMS); 

(2) Multimedia Broadcast/Multicast Service Control Module (MBMSC) requests 
1 5 Broadcast/Multicast Control protocol (BMC) with a primitive to send the service 

announcement message or service notification message of Multimedia 
Broadcast/Multicast Service (MBMS), wherein said primitive includes the 
necessary parameters for constructing the service announcement message or 
service notification message of Multimedia Broadcast/Multicast Service 
20 (MBMS); 

(3) BMC constructs the service announcement message or service notification 
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message of Multimedia Broadcast/Multicast Service (MBMS), saves it in its 
own sending memory block, and starts up a counter for this message, and the 
initial value of the counter is equal to the required times for sending the message, 
and if the message is required to send for infinite times, the initial value of the 
5 counter is assigned with zero or negative value; 



(4) BMC estimates the transmission rate (Vneed) needed on the Common Traffic 
Channel ( CTCH) according to all messages currently saved in the sending 
memory block, wherein said all messages include the service announcement 

10 message or service notification message of Multimedia Broadcast/Multicast 
Service (MBMS) and other broadcast messages, and if the actual transmission 
rate (Vetch) on the CTCH is 0, it means that this cell hasn't allocated CTCH 
resources and it won't continue to send broadcast message, and if the actual 
transmission rate is much smaller or larger than that needed on the CTCH, BMC 

15 reports the actual required transmission rate to Radio Resource Communication 
{RRC) with a primitive and requests RRC to establish or adjust CTCH resources, 
during the period of BMC waiting for CTCH resources configured by RRC, if 
the actual transmission rate does not match with that required and it isn't equal 
to zero: when the actual transmission rate is much smaller than that required, 

20 BMC can still select some messages with high priority and short length to 
transfer; when the actual transmission rate is much larger than that needed, BMC 
also reports to RRC, but at this time, resources on CTCH will be wasted; 

-17- 



Patent Application No. 10/524.715 
Substitute Specification 
Docket: 678-1881-4— 



(5) RRC controls LI and L2 with a primitive to establish CTCH or adjust CTCH 
configuration to make CTCH transmission rate match, and RRC informs BMC 
the new configuration parameters of CTCH with a primitive, and only if the 

5 actual transmission rate is not equal to zero, BMC will still continue to send the 
broadcast message as described in step (4); 

(6) BMC adds descriptions for the service announcement message or service 
notification message of Multimedia Broadcast/Multicast Service (MBMS) to a 

10 pending-for-sending schedule message, and then BMC arranges the service 
announcement message or service notification message of Multimedia 
Broadcast/Multicast Service (MBMS) on a certain position of the schedule 
period following the schedule message for future sending; 

1 5 (7) BMC sends the schedule message; 

(8) BMC sends the service announcement message or service notification 
message of Multimedia Broadcast/Multicast Service (MBMS) at the prescribed 
time; 

20 

(9) After reducing the counter's value by 1, BMC judges: if the value of the 
counter is negative, it means that the service announcement message or service 
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notification message of Multimedia Broadcast/Multicast Service (MBMS) is 
required to send infinite times, then proceeding to step (10) after adding 1 to the 
value of the counter; if the value of the counter is positive, proceeding to step 
(10) directly; if the value is zero, it means that the times of sending the service 
5 announcement message or service notification message of Multimedia 
Broadcast/Multicast Service (MBMS) has met the requirement, then BMC 
returns the confirmation information to Multimedia Broadcast/Multicast Service 
Control Module (MBMSC) with a primitive and the process of sending service 
announcement message or service notification message of Multimedia 
10 Broadcast/Multicast Service (MBMS) is completed; 

(10) BMC waits on-timing according to the time interval that the service 
announcement message or service notification message of Multimedia 
Broadcast/Multicast Service (MBMS) is required to send, when the time expires 
15 for sending the next service announcement message or service notification 
message of Multimedia Broadcast/Multicast Service (MBMS), proceeding to 
step (6). 

The step of the UE receiving the service announcement message or 
20 service notification message of Multimedia Broadcast/Multicast Service 
(MBMS) via cell broadcast further includes the following steps: 
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(1) Multimedia Broadcast/Multicast Service Control Module (MBMSC) sends a 
request to BMC with a first primitive for receiving a service announcement 
message or a service notification message of Multimedia Broadcast/Multicast 
Service (MBMS); 

5 

(2) If BMC hasn't received any broadcast message before, proceeding to step 

(3) ; otherwise, proceeding to step (9); 

(3) BMC informs RRC to receive broadcast message with a second primitive, 
10 which includes the parameters that can inform RRC only to receive a BMC 

preferred message at the prescribed time and to skip some messages; 

(4) .If RRC has not configured CTCH before, RRC configures link layer (L2) and 
physical layer (LI) to enable UE to receive information on the CTCH and 

15 feedbacks necessary CTCH configuration information with a third primitive to 
BMC at the same time, thereafter proceeding to step (5); if RRC has configured 
CTCH resources before, proceeding to step (5) directly; 

(5) According to the requirement of BMC, RRC controls L2 and LI with a 
20 fourth primitive to receive cell broadcast information on the CTCH at the 

prescribed time; 
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(6) After processing the data frame received from the CTCH accordingly, LI and 
L2 submit it to BMC in the format of BMC message with a fifth primitive; 

(7) BMC analyses the received message, and if it is the service announcement 
5 message or service notification message of Multimedia Broadcast/Multicast 

Service (MBMS), BMC forwards it to Multimedia Broadcast/Multicast Service 
Control Module (MBMSC) with a sixth primitive, at the same time the reception 
is completed; if it is not the service announcement message or service 
notification message of Multimedia Broadcast/Multicast Service (MBMS), 
1 0 proceeding to step (8); 

(8) If the message received by BMC is the schedule message, proceeding to step 

(9) ; otherwise, proceeding to step (3); 

15 (9) BMC analyses the schedule message that was received most recently, and 
checks whether the schedule period described by the schedule message includes 
the service announcement message or service notification message of 
Multimedia Broadcast/Multicast Service (MBMS) or not. If it is positive, 
proceeding to step (12), otherwise, BMC finds the position of the next schedule 

20 message and requests RRC to receive the next schedule message with the second 
primitive; 
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(10) RRC controls LI and L2 to receive the next schedule message at the 
prescribe time with the fourth primitive; 

(11) After processing the message received from the CTCH accordingly, LI and 
5 L2 forward the schedule message to BMC with the fifth primitive, and then 

proceeding to step 9); 

(12) BMC finds the position of the Multimedia Broadcast/Multicast Service 
(MBMS) service announcement message or service notification message, and 

10 requests RRC to receive Multimedia Broadcast/Multicast Service (MBMS) 
service announcement message or service notification message at the prescribed 
time with the second primitive; 

(13) RRC controls LI and L2 to receive the Multimedia Broadcast/Multicast 
1 5 Service (MBMS) service announcement message or service notification message 

at the prescribed time with the fourth primitive; 

(14) After processing the message received from the CTCH accordingly, LI and 
L2 forward the Multimedia Broadcast/Multicast Service (MBMS) service 

20 announcement message or service notification message to BMC with the fifth 
primitive; 
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(15) BMC forwards the Multimedia Broadcast/Multicast Service (MBMS) 
service announcement message or service notification message to Multimedia 
Broadcast/Multicast Service (MBMS) with the third primitive and the reception 
is completed. 

5 

BRIEF DESCRIPTION OF THE DRAWINGS 



The above and other features and advantages of the present invention 
will be more apparent from the following detailed description taken in 
10 conjunction with the accompanying drawings, in which: 



Figure 1 illustrates a diagram of logical network apparatuses that can provide 
MBMS service^ 

Figure 2 illustrates a flow of MBMS multicast service^ 

1 5 Figure 3 illustrates a flow of MBMS broadcast servicer; 

Figure 4 illustrates a flow of UE receiving MBMS multicast service data;T 
Figure 5 illustrates a flow of UTRAN sending MBMS multicast service data;r 
Figure 6 illustrates a flow of UE receiving MBMS broadcast service data;? 
Figure 7 illustrates a flow of UTRAN sending MBMS broadcast service data;T 

20 Figure 8 illustrates a message flow of a service announcement process in MBMS 
service^ 

Figure 9 illustrates a message flow of a data transfer in MBMS service^ 
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Figure 10 illustrates a functional diagram that explains the process of a service 
announcement and a service notification in MBMS service: ^ and 
Figure 11 illustrates an example of mapping CTCH onto S-CCPCH. 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

A message flow of a service announcement process in MBMS multicast 

service. 

In order to explain the process of a service announcement in MBMS service, 
Figure 8 gives a message flowchart of a service announcement process, which 
includes the parts of UE receiving and UTRAN sending. The description is as 
follows: 

In Step 80 It. BMJSC requests CBC to send a service announcement in the 
service area of MBMS service through a signaling message. This request may 
include sending times and sending time duration as parameters and the sending 
times can be infinite times. 

In Step 802t, CBC commands UTRAN connected with it by a signaling message 
to send the service announcement; according to the requirement of BMJSC, Cell 
Broadcast Center (CBC) may require UTRAN to send the service announcement 
periodically a plurality of times or infinite times. 
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In Step 803t. UTRAN arranges the time for sending the Multimedia 
Broadcast/Multicast Service (MBMS) service announcement message in proper 
time of one or more schedule periods according to the requirement of Cell 
5 Broadcast Center (CBC), adds the brief description information to the schedule 
message that describes each schedule period and sends the schedule message. 
After receiving the schedule message, UE analyses the schedule message and 
configures its physical layer to prepare for receiving the Multimedia 
Broadcast/Multicast Service (MBMS) service announcement message. 

10 

In Step 804t. UTRAN sends the MBMS service announcement message at 
prescribed time. According to the requirement of CBC, the MBMS service 
announcement message may be sent a plurality of times, and therefore step -steps 
803 and 804 may be repeated a plurality of times without a certain precedence 
15 order. 

In Step 805t. Afte^ -after the U TRAN completes the sending of the MBMS 
service announcement message, it sends a confirmation message to CBC. 

20 In Step 806t. AfteF -after r eceiving the confirmation message from UTRAN, CBC 
returns a confirmation message to BM_SC subsequently. 
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The flow of a MBMS service announcement is the same as that of a 
MBMS broadcast service. 

A transfer process of a MBMS multicast service data including MBMS 
5 service notification process. 

The function of MBMS service notification is to inform UE the 
forthcoming MBMS data so that UE can prepare radio resources. Figure 9 is an 
example of a MBMS data transfer. The function of the MBMS service 
1 0 notification will be explained with reference to the flow of this example: 

In Step 901. the B M SC initiates an MBMS data transfer and sends 
MBMS data to GGSN. 

1 5 In Step 902, the GGSN sends the data to SGSN by tunneling technique. 

In Step 9 03. the SGSN informs UTRAN about the forthcoming of the 
MBMS data by a signaling message. 

20 In Step 904. a_Radio data Access Bearer (hereinafter referred to as RAB) 

is established between UTRAN and SGSN. 
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In Step 9 05. the_SGSN sends MBMS data to UTRAN via RAB. Step 
Steps 905. 906 and 907 are executed without a certain precedence order. 

In Step 906. UMTS Terrestrial Radio Access Network (UTRAN) 
arranges the time for sending the Multimedia Broadcast/Multicast Service 
(MBMS) service notification message, which includes to arrange it in proper 
time of one or more schedule periods for sending, to add the brief description 
information to the schedule message that describes each schedule period and to 
send the schedule message; after receiving the schedule message, UE analyses 
the schedule message and configures its physical layer to prepare for receiving 
the MBMS service notification message. 

In Step 907. UTRAN sends the MBMS service notification message at 
the prescribed time. 

In Step 9 08. UE requests UTRAN to allocate Radio resources (RB) by a 
signaling message. It is possible that there are a plurality of UEs to send requests 
to UTRAN simultaneously at this time. 

In Step 909. UTRAN allocates gadie -Radio Bearerb eafef (hereinafter 
referred to as RB) according to the number of UEs and other comprehensive 
factors, and informs UE. 
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In Step 910, UTRAN sends the MBMS data to UE via RB. 

The data transfer flow of MBMS broadcast service is similar with that of 
5 multicast service, except that it does not need step 908. 

SA process of UE receiving a MBMS service announcement message 

For the UE, the process of receiving a MBMS service announcement 
10 message in multicast service and in broadcast service is the same. This process 
will be explained in the following with reference to the functional diagram of 
Figure 10: 

1. When MBMSC (MBMS Service Control module) decides to receive a MBMS 
15 service announcement message, MBMSC sends a request to BMC 

(Broadcast/Multicast Control protocol) with primitive P' 1; 

2. If BMC has never received any broadcast message before, proceeding to step 
3; otherwise, proceeding to step 9; 

20 

3. BMC informs RRC to receive the broadcast message with primitive CI. The 
parameters included in C'l may inform RRC to receive RMC preferred message 
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only at prescribed time and skip some messages. But in step 3, BMC must 
require RRC to receive all continuous broadcast messages; 

4. If RRC has not configured CTCH before, RRC configures link layer (L2) and 
physical layer (LI) to enable UE to receive information on the CTCH and 
feedbacks necessary CTCH configuration information to BMC with primitive 
C'2 at the same time, then proceeding to step 5; if RRC has configured CTCH 
resources before, proceeding to step 5 directly; 



10 5. According to the requirement of BMC, RRC controls L2 and LI with 
primitive C'3 to receive Cell Broadcast Information on the CTCH at the 
prescribed time; RRC may control LI to continuously receive CTCH B lock Set 
(CTCH Bleek-Set) or skip some CTCH BSs; 

15 6. After processing the data frame received from the CTCH accordingly, LI and 
L2 submit it to BMC in the format of BMC message (i.e. BMC PDU) with 
primitive P'3. PDU means Protocol Data Unit, which indicates the message 
format that BMC can identify and create; 

20 7. BMC analyses the received message. If it is MBMS service announcement 
message, BMC forwards it with primitive P'2 to MBMSC, at the same time, the 
reception of this time is completed; otherwise, proceeding to step 8; 
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8. If the message received by BMC is a schedule message, proceeding to step 9; 
otherwise, proceeding to step 3; 

5 9. BMC analyses the schedule message that was received most recently, and 
checks whether the schedule period described by the schedule message includes 
the Multimedia Broadcast/Multicast Service (MBMS) service announcement 
message. If so, proceeding to step 12; otherwise, BMC finds the position of the 
next schedule message and requests RRN to receive the next schedule message 
1 0 with primitive CM ; 

10, RRC controls LI and L2 with primitive C'3 to receive the next schedule 
message at the prescribed time; 

15 11. After processing the message received from the CTCH accordingly, LI and 
L2 forward the schedule message to BMC with primitive P'3, then proceeding to 
step 9; 

12. BMC finds the position of MBMS service announcement message, and 
20 requests RRC with primitive CI to receive MBMS service announcement 
message at the prescribed time; 
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13. RRC controls LI and L2 with primitive C'3 to receive MBMS service 
announcement message at the prescribed time; 

14. After processing the message received from the CTCH accordingly, LI and 
5 L2 forwards MBMS service announcement message to BMC with primitive P'3; 

15. BMC forwards the MBMS service announcement message to MBMS with 
primitive P'2 and the reception of this time is completed. 

10 Notic e : 

It is noted that a C ell -cell b roadcast is transferred through Common 

Traffic Channel (CTCH), which is a logical channel and is multiplexed with 
other logical channels into transfer channel FACH together by Medium Access 
Control sublayer MAC. FACH is then multiplexed together with other transfer 
15 channels into physical channel S-CCPCH by physical layer (PHY). An example 
of CTCH being eventually mapped onto S-CCPCH is shown in Figure 11, in 
which CTCH is assigned periodically on the S-CCPCH, and this period is called 
as CTCH Transfer Interval (CTCH TTI). One CTCH BS that includes the whole 
or part content of Cell Broadcast Message can be transferred in a CTCH TTI. 

20 

Schedule period is composed of a group of CTCH BSs (from 1 to 255). 

The introduction of schedule period makes CTCH BSs transferred on the CTCH 
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be-is_organized into a continuous schedule period. 

SA process of UTRAN sending MBMS service announcement message 

5 For UTRAN, the process of sending MBMS service announcement 

message in multicast service and in broadcast service is the same. In addition, 
this process in all cells controlled by the UTRAN is the same also. This process 
will be explained in the following with reference to the functional diagram of 
Figure 10 by way of one cell as an example: 

10 

1. MBMSC receives a signaling message Ml sent from core network node. Here, 
Ml informs UTRAN to perform the process of MBMS service announcement. 
Ml includes necessary parameters for MBMS service announcement, such as 
times for sending MBMS service announcement and the time interval. The core 

1 5 network node that sends M 1 signaling message can be SGSN or CBC; 

2. MBMSC requests BMC with primitive PI to send MBMS service 
announcement message. The primitive PI includes necessary parameters for 
constructing MBMS service announcement message; 

20 

3. After receiving the primitive PI, BMC constructs MBMS service 
announcement message and saves it in its own sending memory block, and starts 
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up a counter for this message. The initial value of the counter is equal to the 
required times of sending message. If the message is required to send for infinite 
times, the initial value of the counter is assigned with zero or negative value; 

5 4. BMC estimates transmission rate (hereinafter referred to as Vneed) needed on 
the CTCH according to all messages (including MBMS service announcement 
messages and other broadcast messages) currently saved in the sending memory 
block. If the actual transmission rate (hereinafter referred to as Vetch) on the 
CTCH is 0 (i.e. this cell hasn't allocated CTCH resources) or is much smaller or 

10 larger than Vneed, BMC reports the actually needed transmission rate Vneed to 
RRC with primitive CI and requests RRC to establish or adjust CTCH resources. 
During the period of BMC waiting for RRC configuring CTCH resources, if 
Vetch does not match but it isn't equal to zero: when Vetch is smaller than 
Vneed, BMC can still select some messages with high priority and short length 

15 to transfer; when Vetch is much larger than Vneed, resources on CTCH can 
completely meet the need of message transfer, but it will only result in waste. So 
as described above, BMC still needs to report to RRC; 

5. RRC controls LI and L2 with primitive C3 to establish CTCH or adjust 
20 CTCH configuration to make CTCH transmission rate match with Vneed. RRC 
informs BMC the new configuration parameters of CTCH with primitive C2. 
What need to be mentioned is that after BMC receives the primitive C2, whether 
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CTCH resource adjustment is performed successfully by RRC or not, only if 
Vetch is not equal to zero, BMC will still continue to send broadcast message as 
described in step 4; 

5 6. BMC adds descriptions for MBMS service announcement message to a 
pending-for-sending schedule message, and then BMC arranges MBMS service 
announcement message on a certain position of the schedule period following 
the schedule message for future sending; 

10 7. BMC sends the schedule message with primitive P3; 

8. BMC sends MBMS service announcement message at the prescribed time 
with primitive P3; 

15 9, After reducing the counter's value by one, BMC judges: if the value of the 
counter is negative, it means that MBMS service announcement message is 
required to send for infinite times, then proceeding to step 10 after adding 1 to 
the value of the counter; if the value of the counter is positive, proceeding to step 
10 directly; if the value is zero, it means that the times of sending MBMS service 

20 announcement message has reached the requirement, then BMC returns 
confirmation information to MBMSC with primitive P2 and the process of 
MBMS service announcement for this time is completed; 
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10. BMC waits on-timing according to the time interval that MBMS service 
announcement message is required to send, and when the time expires for 
sending the next MBMS service announcement message, proceeding to step 6. 

5 

QA process of UE receiving MBMS service notification message 

For UE, the process of receiving MBMS service notification message in 

multicast service and in broadcast service is the same. This process will be 
10 explained in the following with reference to the functional diagram of Figure 10: 

1. When MBMSC (MBMS Service Control module) decides to receive MBMS 
service notification message, MBMSC sends a request to BMC 
(Broadcast/Multicast Control protocol) with primitive P* 1; 

15 

2. If BMC has never received any broadcast message before, proceeding to step 
3; otherwise, proceeding to step 9; 

3. BMC informs RRC to receive the broadcast message with primitive CI. The 
20 parameters included in C'l can inform RRC to receive RMC preferred message 

only at prescribed time and skip some messages. But in step 3, BMC must 
require RRC to receive all continuous broadcast messages; 
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4. If RRC has not configured CTCH before, RRC configures link layer 
(hereinafter referred to as L2) and physical layer (hereinafter referred to as LI) 
to enable UE to receive information on the CTCH and feedbacks necessary 

5 CTCH configuration information with primitive C2 to BMC at the same time, 
thereafter proceeding to step 5; if RRC has configured CTCH resources before, 
proceeding to step 5 directly; 

5. According to the requirement of BMC, RRC controls L2 and LI with 
10 primitive C'3 to receive Cell Broadcast Information on the CTCH at the 

prescribed time; RRC can control LI to continuously receive CTCH BS or skip 
some CTCH BSs; 

6. After processing the data frame received from the CTCH accordingly, LI and 
15 L2 submit it to BMC in the format of BMC message (i.e. BMC PDU) with 

primitive P'3. PDU means Protocol Data Unit, which indicates the message 
format that BMC can identify and create; 

7. BMC analyses the received message. If it is a MBMS service notification 
20 message, BMC forwards it to MBMSC with primitive P'2, at the same time, the 

reception of this time is completed; otherwise, proceeding to step 8; 
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8. If the message received by BMC is a schedule message, proceeding to step 9; 
otherwise, proceeding to step 3; 



9. BMC analyses the schedule message that was received most recently, and 
5 checks whether the schedule period described by the schedule message includes 
MBMS service notification message. If so, proceeding to step 12; otherwise, 
BMC finds the position of the next schedule message and requests RRC to 
receive the next schedule message with primitive C'l; 

10 10. RRC controls LI and L2 with primitive C'3 to receive the next schedule 
message at the prescribed time; 

11. After processing the message received from the CTCH accordingly, LI and 
L2 forwards the schedule message to BMC with primitive P'3 and then 

1 5 proceeding to step 9; 

12. BMC finds the position of the MBMS service notification message and 
requests RRC with primitive C'l to receive MBMS service notification message 
at prescribed time; 

20 

13. RRC controls LI and L2 with primitive C'3 to receive MBMS service 
notification message at the prescribed time; 
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14. After processing the message received from the CTCH accordingly, LI and 
L2 forward the MBMS service notification message to BMC with primitive P'3; 
and 

5 

15. BMC forwards the MBMS service notification message to MBMSC with 
primitive P'2 and the reception of this time is completed. 

■BA process of UTRAN sending a MBMS service notification message 

10 

For UTRAN, the process of sending MBMS service notification 
message in multicast service and in broadcast service is the same. In addition, 
this process in all cells controlled by the UTRAN is the same also. This process 
will be explained in the following with reference to the functional diagram of 
1 5 Figure 10 by way of one cell as an example: 

L MBMSC receives the signaling message M2 sent from core network node. 
Here, M2 informs UTRAN to perform the process of MBMS service notification. 
M2 includes n e o e ssorv necessary p arameters for MBMS service notification, 
20 such as times for sending MBMS service announcement and the time interval. 
The core network node that sends M2 signaling message can be SGSN or CBC; 
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2. MBMSC requests BMC to send MBMS service notification message with 
primitive PI. The primitive PI includes necessary parameters for constructing 
MBMS service notification message; 

5 3. After receiving the primitive PI, BMC constructs MBMS service notification 
message and saves it in its own sending memory block, and starts up a counter 
for this message. The initial value of the counter is equal to the required times of 
sending message. If the message is required to send for infinite times, the initial 
value of the counter is assigned with zero or negative value; 

10 

4. BMC estimates transmission rate (hereinafter referred to as Vneed) needed on 
the CTCH according to all messages (including MBMS service notification 
messages and other broadcast messages) currently saved in the sending memory 
block. If the actual transmission rate (hereinafter referred to as Vetch) on the 

15 CTCH is 0 (i.e. this cell hasn't allocated CTCH resources) or is much smaller or 
larger than Vneed, BMC reports the actually needed transmission rate Vneed to 
RRC with primitive CI and requests RRC to establish or adjust CTCH resources. 
During the period of BMC waiting for RRC configuring the CTCH resources, if 
Vetch does not match but it isn't equal to zero: when Vetch is smaller than 

20 Vneed, BMC can still select some messages with high priority and short length 
to transfer; when Vetch is much larger than Vneed, resources on CTCH can 
completely meet the need of message transfer, but it will only result in waste. So 
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as described in above, BMC still needs to report to RRC; 

5. RRC controls LI and L2 with primitive C3 to establish CTCH or adjust 
CTCH configuration to make CTCH transmission rate match with Vneed. RRC 

5 informs BMC the new configuration parameters of CTCH with primitive C2. It 
should be noticed that after BMC receives the primitive C2, whether CTCH 
resource adjustment performed successfully by RRC or not, only if Vetch is not 
equal to zero, BMC will still continue to send broadcast messages as described 
in step 4; 

10 

6. BMC adds descriptions for MBMS service notification message to a pending- 
for-sending schedule message, and then BMC arranges MBMS service 
notification message on a certain position of the schedule period following the 
schedule message for future sending; 

15 

7. BMC sends the schedule message with primitive P3; 

8. BMC sends MBMS service notification message at the prescribed time with 
primitive P3; 

20 

9. After reducing the counter's value by one, BMC judges: if the value of the 
counter is negative, it means that MBMS service notification message is required 
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to send for infinite times, then proceeding to step 10 after adding 1 to the value 
of the counter; if the value of the counter is positive, proceeding to step 10 
directly; if the value is zero, it means that the times of sending MBMS service 
notification message has met the requirement, then BMC returns confirmation 
5 information to MBMSC with primitive P2 and the process of MBMS Service 
notification for this time is completed; and 

10. BMC waits on-timing according to the time interval that MBMS service 
notification message is required to send. When the time expires for sending the 
10 next MBMS service notification message, proceeding to step 6. 

G-Messaee structures used in the processes of MBMS service announcement and 
MBMS service notification 

♦5 Schedule message 

A schedule message occupies one or more CTCH BSs included in a 
schedule period. The schedule message describes the schedule period that 
directly follows the schedule message to which the schedule message belongs, 
20 which makes continuous schedule messages be able to describe continuous 
schedule periods. Its structure is shown in Table 1 . 
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Information Element 
(IE) 


Need 


Plurality 
existence 


Semantics description 


Message Type 


necessary 






Offset to Begin CTCH 

BS j n dex 


necessary 






Length of Scheduling 
Period 


necessary 






New Message Bitmap 


necessary 






Message Description 


necessary 


1 To <the 
length of 
schedule 
period> 


Message description 
includes a plurality of 
items, wherein each item 
describes the message 
content included in one 
CTCH BS of the 
schedule period. The i-th 
item corresponds to the i- 
th bit of new message 
bitmap* 



Table 1 structure of schedule message 



Message Type, the sub-information element in schedule message, is 
included in all the cell broadcast message. It describes the message types, whose 
coding is shown in Table 2. 



1 


CBS Message 


2 


Schedule Message 


3 


CBS41 Message 


: 4 


MBMS Service Announcement 




MBMS Service Notification 
Message 


0, 6...255 


Reserved for future use (PDU with 
any coding herein shall be discarded 
by the protocol of this version.) 



Table 2 Coding of Information Element in Schedule Message 
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New message bitmap, the sub-information element in schedule message, 
is a map of bits, each bit of which corresponding to a CTCH BS in the schedule 
period. The bit value is 1, which indicates that CTCH BS includes a new 
5 message, and the bit value is 0, which indicates that CTCH BS includes an old 
message, whose structure is shown in Table 3. 



CTCH 

BS 
Index 

B 


CTCH 

BS 
Index 

B+1 


CTCH 

BS 
Index 

B+2 












1 


















2 


















• •• 




• • ■ 


CTCH 

BS 
Index 

E-1 


CTCH 

BS 
Index E 


0 


0 


0 


0 


n 



Table 3 structure of new message bitmap of Information Element in 
schedule message 



10 

There is a plurality of sub-information element message descriptions in a 
schedule message, whose number is equal to the number of CTCH BSs included 
in the schedule period described by the schedule message. Each CTCH BS is 
described by one message description, whose structure is shown in Table 4. 

15 



Information 


Need 


Type 


Semantics 


Element 






description 


(IE) 
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Message 

Description 

Type 


necessary 


Enumerated value 
(0..255) 
Table 5 




Message ID 


Decision 
condition 
MDT11 


Enumerated value 
(0 2 ,6 -l) 




Offset to 
CTCH BS 
index of first 
transmission 


Decision 
condition 
MDT22 


Integer (0..255) 




service 

Identity ;j 


iD^clsiwi'H J'" ; 0 , 
[condition 


jlP' multicast address 


Tm^ Information < - 

Element teia^$f&i 

identify the types of . 
MBMS service. 


Identity 


[Decision 
eotim'tidn/ 

|MDT44 : - .; / 


IWBltlli IB 


"This Information ; : 
iiieincnt is used! jq; ; ; ; ■ ' ' 
identify the types of 
!MBMS service. 



Table 4 structure of Information Element Message description in schedule 



message 

The types of the message included by CTCH BSs are described by the Sub- 
information Element Message Description Type of Message Description 
Information Element, whose coding is shown in Table 5. 
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Values 


Interpretation 


0 


Repetition of new BMC message within schedule period 


1 


New message 


1 2 


Reading advised 


3 


Reading optional 


4 


Repetition of old BMC message within schedule period 


5 


Old message 


6 


Schedule message 


7 


CBS41 message 




i MBMS serace announcement message j / / 


mwmm 


F " IMBMS;liei§p(^ notification! message ^ 


i 10.255 


Reserved for future use 



Table 5 Coding of the types of Sub-information Element Message 
Description in Message Description Information Element 



Since except for Message Description Types, other Sub-information 
Elements do not absolutely exist, their existence is determined by the decision 
conditions. The decision condition for each Sub-information existence is shown 
in Table 6. 
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Decision condition 


Interpretation 


MDT11 


If Message Description Types = 1 or 5, then: 
The Information Element of Message Identity exists. 


MDT22 


If Message Description Types = 0 or 4, then: 
The Information Element of Offset to CTCH BS 
index of first transmission exists and indicates the 
offset of CTCH BS that is the first one including 
broadcast message in this schedule period to schedule 
message. 




T ^ 

1 ; 

a 1 j 


announcement message) and the message structure in 
Table 8 is selected for use, then: ; y-lilBS- Wtti', ■ 
The Information Element of MBMS service Identity: 






;tiotific]at|j^^ f§-. 
^eTnfermation demerit -Q|^^^fcyice 



Table 6 Decision Conditions for deciding whether a certain Sub-information 
Elements exist in Information Element Message Description 



MBMS service announcement message 



MBMS service announcement message describes parameters such as 
MBMS service types and service areas, and may have two kinds of structures: 
the first kind of structure describes a plurality of MBMS services, as shown in 
Table 7; and the second kind of structure describes single MBMS service, as 
shown in Table 8. 
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Information Element 
(IE) 


Need 


Semantics description 


Message Type 


necessary 




Service Number 


necessary 

✓ 


The number of MBMS services 
described in the message 


MBMS service Identity 1 




The Identity of the first MBMS 
service: IP multicast address 


APM 1 




1 11C UUIIlalll Ilallic Ul atLCso 

point, for pointing to one 
GGSN 


UE capability 1 




The capability of UE required 
by the first MBMS service 








MBMS service Identity n 




The Identity of the n-th MBMS 
service, n = Service Number 


APNn 






UE capability n 




The capability of UE required 
by the n-th MBMS service 



Table 7 structure of the first kind of MBMS service announcement message 



Information Element 
(IE) 


Need 


Semantics 
description 


Message Type 


necessary 




MBMS Service Identity 




Identity of this MBMS 
service: IP multicast 
address 


APN 






UE capability 







-Table 8 structure of the second kind of MBMS service announcement 
message 
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QMBMS Service notification message 



MBMS service notification message is notification information about a 
5 certain forthcoming MBMS service and informs UE to prepare for the MBMS 
service. Its structure is shown in Table 9. 



Information Element 
(IE) 


Need 


Semantics 
description 


Message Type 


necessary 




MBMS Service Group 
Identity 


necessary 


Identity of this MBMS 
service group: TMGI 


QoSQOS 


necessary 


Quality of Service that 
can be provided by 
this MBMS service 


Random Mechanism 


Optional 


Pre-coding random 
mechanism 


Random Value 


Optional 




Mask Value 


Optional 





Table 9 structure of MBMS service notification message 



10 To avoid the-air congestion r e sult e d from simultaneous responses to access 

network when a plurality of UEs receive MBMS service notification message 
simultaneously, there should be such a mechanism that allows large number of 
UEs to respond at different time. Sub-information Element random mechanism, 
random value and mask value in the MBMS service notification message are all 
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set for this. Random mechanism indicates which operation mode to be used by 
coding. IMSI of UE (the unique ID of an UE over the world), random value and 
mask value are participated in operation together and the operation results is 
used as time delay that UE initiates a response with time as the unit (e.g. 
millisecond). Table 10 shows the coding modes of random mechanism. 



0 


After IMSI modulo the random value, performing 
bit-by-bit AND operation with the mask value. 


1 


After IMSI adding to the random value, 
performing bit-by-bit AND operation with the 
mask value. 


2 


After IMSI multiplying with the random value, 
performing bit-by-bit AND operation with the 
mask value. 


3 


After IMSI dividing by the random value, 
performing bit-by-bit AND operation with the 
mask value. 



Table 10 coding of random mechanism of Sub-information Element in 
MBMS service notification message 



Effects of the invention 

4- BAs noted from the above description, the present invention effectively 

Effectively us e uses the network resources* since the processes of MBMS 
service announcement and service notification are all performed via cell 
broadcast, the one-to-multiple characteristic of cell broadcast reduces the load of 
resources resulted from these two processes effectively.! 
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2 SIn addition, the present invention effectively Eff e ctiv e ly r e duc e reduces 
the-standby time of UEst since cell broadcast enable UEs to receive cell 
broadcasts in discontinuous mode, it romarkablel v remarkablv increasing 
increases the lifetime of UEs' batteries; 

The present invention also improves scalabilit v Soalability: since cell 
broadcast uses messages of variable length, jt-ean -therebv effectively adding a dd 
parameters for future use e ff e ctiv e ly . 
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ABSTRACT 

The present invention propoaoo q A method of making use of Cell 
Broadcast to support MBMS transfer service announcement or service 
notification transfer. The method of transferring service announcement 
5 oomprisos the following includes stepsr of a_CBC commands commanding a 
UTRAN connected with it by a signaling message to send a_service 
announcement; the UTRAN arranges the prescribed time of sending the MBMS 
service announcement message, adds the brief description information to the 
schedule message and sends the schedule message; after receiving the schedule 
10 message, a_UE configures a_physical layer thereof to prepare for receiving the 
MBMS service announcement message. UTARN T he UTRAN s ends MBMS 
service announcement message at the prescribed time. 
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USING CELL BROADCAST FOR MBMS SERVICE 
ANNOUNCEMENT AND NOTIFICATION 

PRIORITY 

5 This application claims priority to an application filed in the Chinese 

Industrial Property Office on August 15, 2002, assigned Serial No. 02130506.4, 
as well as to application PCT/KR03/01648 filed August 14, 2003, the contents of 
which are incorporated herein by reference. 

10 Background of the invention 

1. Field of invention 

The present invention relates to a method for sending and receiving 
15 Multimedia Broadcast/Multicast Service (MBMS) data in communication 
system, especially to a method of sending and receiving service announcement 
and service notification in Multimedia Broadcast/Multicast Service with the aid 
of using cell broadcast. 

20 2. Description of the prior art 

Multimedia Broadcast/Multicast Service (hereinafter referred to as 
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MBMS) is a new service under standardization by 3 rd Generation Partnership 
Project (hereinafter referred to as 3GPP). The standard being developed is 
TS23.846, whose latest version is 1.1.1. MBMS service is a unidirectional 
point-to-multipoint (p-t-m) service, whose most remarkable characteristic is that 
5 it can make use of radio resources and network resources efficiently. 



A system structure of MBMS is described in the following with 
reference to Figure 1. As shown in Figure 1, the MBMS network structure is 
based on the core network of General Packet Radio Service (hereinafter referred 

10 to as GPRS), and further adds new network elements. Broadcast and multicast 
service center 101 (hereinafter referred to as BM-SC) is the service control 
center of MBMS system. Gateway GPRS Supporting Node 102 (hereinafter 
referred to as GGSN) and Service GPRS Supporting Node 103 (hereinafter 
referred to as SGSN) compose the transmission network of MBMS service and 

15 provide routing for the transmission of data. Home Location Register 106 
(hereinafter referred to as HLR) stores the data related to a user and can provide 
services such as user's authentication. Universal Mobile Telecommunication 
System (UMTS) Terrestrial Radio Access Network 104 (hereinafter referred to 
as UTRAN) provides radio resources for MBMS service over the air-interface. 

20 Uul07 indicates a radio interface between terminal and access network. User 
Equipment 105 (hereinafter referred to as UE) is a terminal device for receiving 
data. Cell Broadcast Center 108 (hereinafter referred to as CBC) is a data source 
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of cell broadcast. Radio resources used by MBMS service are not dedicated for 
one user, but are shared by all users using this service. 

A MBMS multicast service flow is described in the following with 
5 reference to Figure 2. As shown in Figure 2, the MBMS multicast service flow 
includes the following steps: 

Subscription step 200 establishes the relationship between user 
and service provider, which allows the user to receive the related MBMS 
multicast service. 

10 Service announcement step 201 informs UEs about the types and service 

areas of forthcoming multicast services. 

Joining step 202 is the process by which a subscriber joins a multicast 
group, i.e. the user registers the network in which the MBMS multicast service 
types that he is willing to receive. 
15 MBMS multicast mode bearer set up step 203 establishes the network 

resources for MBMS multicast data transfer. 

MBMS notification step 204 informs UEs about forthcoming MBMS 
multicast data transfer. 

Data transfer step 205 indicates the phase when MBMS multicast 
20 service data are transferred from the network to the UEs. 

MBMS multicast mode bearer release step 206 indicates to release the 
network resources after MBMS service data transfer finishes. 
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Leaving step 207, corresponding to 202 joining step, indicates that a 
subscriber is leaving a service group, i.e. the user no longer wants to receive 
Multicast mode data of a specific service. 

The necessary flow of providing a MBMS broadcast service is described 
5 with reference to Figure 3. As shown in Figure 3, the MBMS broadcast service 
flow includes the flowing steps: 

Service announcement step 300, which informs UEs about the types and service 
areas of forthcoming services. 

MBMS broadcast mode bearer setup step 301, which establishes the 
10 network resources for MBMS broadcast data transfer. 



MBMS notification step 302, which informs the UEs about the forthcoming 
MBMS broadcast data transfer. 

Data transfer step 303, which indicates the phase when MBMS 
1 5 broadcast data are transferred from the network to the UEs. 

MBMS broadcast mode bearer release step 304, which indicates to 
release the network resources after MBMS broadcast service data transfer 
finishes. 

In the MBMS Multicast service flow shown in Figure 2, the operation in 
20 step 200, 201 and 202 should be performed for different UEs respectively, and 
remaining steps are performed by all UEs in the same type of service. The series 
of steps can be performed repeatedly, and step 200, 201, 203, 204 or 207 can be 
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performed in parallel with other steps. 

In the MBMS broadcast service flow shown in Figure 3, this series of 
steps can be performed repeatedly and step 300 and 302 can be performed in 
5 parallel with other steps. 

A cell broadcast indicates data transfer by using a common service 
channel in a cell so as to enable all UEs staying in the cell capable of receiving 
the broadcast data of the cell. Refer to 3GPP standard TS25.324 (the latest 
10 version is 5.1.0) for the description of cell Broadcast/Multicast Control module 
BMC. 

But in the steps shown in Figure 2 and 3, existing standard TS23.846 
only mentions that service announcement steps can be completed by CBC, but 
15 the implementation method hasn't been given, and no mention is made of what 
devices and how to implement MBMS Service notification steps, making it 
impossible to completely implement MBMS multicast service flow and MBMS 
broadcast service flow. 

20 SUMMARY OF THE INVENTION 

Therefore, an object of the present invention is to provide a method on 
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how to use a cell broadcast to realize MBMS service announcement and MBMS 
service notification so as to make MBMS service be a complete flow. It is noted 
that the Cell Broadcast herein indicates a method of transmitting data via a 
common service channel over a air-interface of the cell, and it does not relates to 
5 specific devices such as CBC. When the cell broadcast is used to support the 
MBMS service announcement or MBMS service notification, messages sent 
from CBC and SGSN can all be sent out through cell broadcast. 

According to one aspect of the present invention, a process of a UE 
10 receiving MBMS multicast service data is shown in Figure 4, and includes the 
following steps: 

Subscription step 400 indicates a process of the UE subscribing a 
specific type of MBMS service, which makes the UE establishing relationship 
15 with the specific type of MBMS and be authorized to receive this specific type 
of MBMS service in the future; 

Service announcement step 401 indicates a process of the UE being 
informed of the MBMS multicast service types and relevant parameters by 
20 receiving the service announcement information included in cell broadcast; 

Joining step 402 indicates a process of the UE joining the specific 
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MBMS service multicast group, which corresponds to the MBMS service one to 
one, the multicast group including all subscribers who receive the MBMS 
service; 

5 MBMS Service notification step 403 indicates that the UE is informed 

that the MBMS multicast service data, which is expected to receive by the UE, is 
forthcoming, by receiving MBMS Service notification information included in 
cell broadcast; 

10 Data transfer step 404 indicates a process of the UE receiving the 

MBMS service multicast data; 

Leaving step 405 indicates a process of the UE leaving the specific 
MBMS service multicast group that it is used to join. 

15 

A process of a UTRAN sending the MBMS multicast service data is 
shown in Figure 5, and includes the following steps: 

Service announcement step 500 indicates that the UTRAN sends information on 
MBMS service types and service areas via cell broadcast; 
20 MBMS multicast mode bearer set up step 501 indicates a process of co- 
establishing the network resources for the MBMS service by the UTRAN and a 
core network; 
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MBMS service notification step 502 indicates that the UTRAN sends a MBMS 
service notification message via cell broadcast, the message indicating a 
forthcoming of a specific MBMS service data, and making all users of this 
multicast group prepare radio resources; 

Data transfer step 503 indicates that the UTRAN sends a real MBMS service 
data; 

MBMS multicast mode bearer release step 504 indicates that after the transfer of 
the MBMS service data being completed, the UTRAN and other devices in the 
core network co-release the network resources for the MBMS multicast service. 

A process of the UE receiving the MBMS broadcast service data is 
shown in Figure 6, and includes the following steps: 

Service announcement step 600 indicates a process of the UE being informed of 
the MBMS broadcast service types and relevant parameters by receiving the 
service announcement information included in the cell broadcast; 
MBMS service notification step 601 indicates that the UE is informed that the 
MBMS broadcast service data, which is expected to receive by the UE, is 
forthcoming, by receiving MBMS service notification information included in 
cell broadcast; 

Data transfer step 603 indicates a process of the UE receiving the MBMS 
broadcast service data; 
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A process of the UTRAN sending the MBMS broadcast service is shown 
in Figure 7,and includes the following steps: 

Service announcement step 700 indicates that the UTRAN sends information on 
MBMS service types and service areas via cell broadcast; 
5 MBMS broadcast mode bearer setup step 701 indicates a process of co- 
establishing the network resources for the MBMS broadcast service by the 
UTRAN and the core network; 

MBMS service notification step 702 indicates that the UTRAN sends a MBMS 
service notification message via cell broadcast, the message indicating a 
10 forthcoming of a specific MBMS service data, and making all users of this 
multicast group prepare radio resources; 

Data transfer step 703, indicates that the UTRAN sends a real MBMS service 
data; 

MBMS broadcast mode bearer release step 704 indicates that after the transfer of 
15 the MBMS service data being completed, the UTRAN and other devices in the 
core network co-release the network resources for the MBMS broadcast service. 

According to another aspect of the present invention, the method for 
transferring service announcement of Multimedia Broadcast/Multicast Service 
20 (MBMS) includes the following steps: 

(a) Broadcast/Multicast Service Center (BMJSC) requests Cell Broadcast Center 
(CBC) to send a service announcement by a signaling message in a Multimedia 



-9- 



Patent Application No. 10/524 ,715 
Substitute Specification 
Docket: 678-1881 

Broadcast/Multicast Service (MBMS) service area, wherein said request can 
include sending times and sending time duration as parameters; 

(b) After receiving the signaling message from BMSC, Cell Broadcast Center 
(CBC) commands UMTS Terrestrial Radio Access Network (UTRAN) 
connected with it to send the service announcement through the signaling 
message; 

(c) UMTS Terrestrial Radio Access Network (UTRAN) arranges the sending of 
Multimedia Broadcast/Multicast Service (MBMS) service announcement 
message in a prescribed time of one or more schedule periods according to the 
requirement of Cell Broadcast Center (CBC), adds brief description information 
to a schedule message for describing each schedule period and sends the 
schedule message; after receiving the schedule message, UE analyzes the 
schedule message and then configures its physical layer to prepare for receiving 
the Multimedia Broadcast/Multicast Service (MBMS) service announcement 
message; and 

(d) UMTS Terrestrial Radio Access Network (UTRAN) sends Multimedia 
Broadcast/Multicast Service (MBMS) service announcement message at the 
prescribed time, 

wherein the transfer times in the step (a) can be a plurality of times or infinite 
times* 

In addition, after UMTS Terrestrial Radio Access Network (UTRAN) 
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completes the sending of the Multimedia Broadcast/Multicast Service (MBMS) 
service announcement message, it may send confirmation information to Cell 
Broadcast Center (CBC). After receiving the confirmation information from 
UTRAN, Cell Broadcast Center (CBC) returns confirmation information to 
BM_SC subsequently. 

In the above step (b), according to the requirement of BM_SC, Cell 
Broadcast Center (CBC) can require UMTS Terrestrial Radio Access Network 
(UTRAN) to send the service announcement periodically a plurality of times or 
infinite times. 

In the above step (d), UMTS Terrestrial Radio Access Network 
(UTRAN) sends the Multimedia Broadcast/Multicast Service (MBMS) service 
announcement message a plurality of times according to the requirement of Cell 
Broadcast Center (CBC), and the step (c) and (d) can be repeated a plurality of 
times without a certain precedence order. 

In addition, the service announcement message includes parameters of 
the Multimedia Broadcast/Multicast Service (MBMS) service types and service 
areas. 

According to another aspect of the present invention, the method for 
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transferring a Multimedia Broadcast/Multicast Service (MBMS) service 
notification includes the following steps: 

(a) BMSC sends the Multimedia Broadcast/Multicast Service (MBMS) data to 
GGSN; 

(b) After receiving said data sent by BM_SC, GGSN sends said data to SGSN by 
tunneling technique; 

(c) After receiving the signals from GGSN, SGSN informs UMTS Terrestrial 
Radio Access Network (UTRAN) of the forthcoming of the Multimedia 
Broadcast/Multicast Service (MBMS) data via a signaling message; 

(d) Radio data Access Bearer (RAB) is established between UMTS Terrestrial 
Radio Access Network (UTRAN) and SGSN; 

(e) SGSN sends the Multimedia Broadcast/Multicast Service (MBMS) data to 
UMTS Terrestrial Radio Access Network (UTRAN) via Radio data Access 
Bearer RAB; 

(f) After receiving the described data from SGSN, UMTS Terrestrial Radio 
Access Network (UTRAN) arranges the sending time of a Multimedia 
Broadcast/Multicast Service (MBMS) service notification message, which 
includes to arrange sending at the prescribed time of one or more schedule 
periods, and to add a brief description information to the schedule message for 
describing each schedule period and to send the schedule message. After 
receiving the schedule message, UE analyzes the schedule message and 
configures its physical layer to prepare for receiving the Multimedia 
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Broadcast/Multicast Service (MBMS) service notification message; 
(g) UMTS Terrestrial Radio Access Network (UTRAN) sends the Multimedia 
Broadcast/Multicast Service (MBMS) service notification message at the 
prescribed time; 

5 (h) UE requests UTRAN to allocate Radio Bearer (RB) via a signaling message, 
and a plurality of UEs can send requests to UMTS Terrestrial Radio Access 
Network (UTRAN) simultaneously; 

(i) UMTS Terrestrial Radio Access Network (UTRAN) allocates the radio bearer 
(RB) according to the number of UEs and other comprehensive factors, and 
10 informs the UE; 

(j) UMTS Terrestrial Radio Access Network (UTRAN) sends the Multimedia 
Broadcast/Multicast Service (MBMS) data to the UE via RB. 

The above step (e), step (f) and step (g) can be performed without a 
1 5 certain precedence order. 

The data transfer flow of MBMS broadcast service is similar with that of 
multicast service, except that it does not need the step (h), and in the step (i), 
UMTS Terrestrial Radio Access Network (UTRAN) allocates radio data bearer 
20 (RB) according to comprehensive factors without consideration of the number of 
UEs. 
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The step of UMTS Terrestrial Radio Access Network (UTRAN) sending 
a service notification or a service announcement message of Multimedia 
Broadcast/Multicast Service (MBMS) data via cell broadcast further includes the 
following steps: 

(1) Multimedia Broadcast/Multicast Service Control Module (MBMSC) receives 
a signaling message sent from the core network nodes (SGSN, CBC), which 
informs UMTS Terrestrial Radio Access Network (UTRAN) to send a service 
announcement message or service notification message of Multimedia 
Broadcast/Multicast Service (MBMS) and includes the necessary parameters for 
constructing the service announcement message or service notification message 
of Multimedia Broadcast/Multicast Service (MBMS); 

(2) Multimedia Broadcast/Multicast Service Control Module (MBMSC) requests 
Broadcast/Multicast Control protocol (BMC) with a primitive to send the service 
announcement message or service notification message of Multimedia 
Broadcast/Multicast Service (MBMS), wherein said primitive includes the 
necessary parameters for constructing the service announcement message or 
service notification message of Multimedia Broadcast/Multicast Service 
(MBMS); 

(3) BMC constructs the service announcement message or service notification 
message of Multimedia Broadcast/Multicast Service (MBMS), saves it in its 
own sending memory block, and starts up a counter for this message, and the 
initial value of the counter is equal to the required times for sending the message, 
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and if the message is required to send for infinite times, the initial value of the 
counter is assigned with zero or negative value; 

(4) BMC estimates the transmission rate ( Vneed) needed on the Common Traffic 
Channel (CTCH) according to all messages currently saved in the sending 
memory block, wherein said all messages include the service announcement 
message or service notification message of Multimedia Broadcast/Multicast 
Service (MBMS) and other broadcast messages, and if the actual transmission 
rate (Vetch) on the CTCH is 0, it means that this cell hasn't allocated CTCH 
resources and it won't continue to send broadcast message, and if the actual 
transmission rate is much smaller or larger than that needed on the CTCH, BMC 
reports the actual required transmission rate to Radio Resource Communication 
(RRC) with a primitive and requests RRC to establish or adjust CTCH resources, 
during the period of BMC waiting for CTCH resources configured by RRC, if 
the actual transmission rate does not match with that required and it isn't equal 
to zero: when the actual transmission rate is much smaller than that required, 
BMC can still select some messages with high priority and short length to 
transfer; when the actual transmission rate is much larger than that needed, BMC 
also reports to RRC, but at this time, resources on CTCH will be wasted; 

(5) RRC controls LI and L2 with a primitive to establish CTCH or adjust CTCH 
configuration to make CTCH transmission rate match, and RRC informs BMC 
the new configuration parameters of CTCH with a primitive, and only if the 
actual transmission rate is not equal to zero, BMC will still continue to send the 
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broadcast message as described in step (4); 

(6) BMC adds descriptions for the service announcement message or service 
notification message of Multimedia Broadcast/Multicast Service (MBMS) to a 
pending-for-sending schedule message, and then BMC arranges the service 

5 announcement message or service notification message of Multimedia 
Broadcast/Multicast Service (MBMS) on a certain position of the schedule 
period following the schedule message for future sending; 

(7) BMC sends the schedule message; 

(8) BMC sends the service announcement message or service notification 
10 message of Multimedia Broadcast/Multicast Service (MBMS) at the prescribed 

time; 

(9) After reducing the counter's value by 1, BMC judges: if the value of the 
counter is negative, it means that the service announcement message or service 
notification message of Multimedia Broadcast/Multicast Service (MBMS) is 

15 required to send infinite times, then proceeding to step (10) after adding 1 to the 
value of the counter; if the value of the counter is positive, proceeding to step 

(10) directly; if the value is zero, it means that the times of sending the service 
announcement message or service notification message of Multimedia 
Broadcast/Multicast Service (MBMS) has met the requirement, then BMC 

20 returns the confirmation information to Multimedia Broadcast/Multicast Service 
Control Module (MBMSC) with a primitive and the process of sending service 
announcement message or service notification message of Multimedia 
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Broadcast/Multicast Service (MBMS) is completed; 

(10) BMC waits on-timing according to the time interval that the service 
announcement message or service notification message of Multimedia 
Broadcast/Multicast Service (MBMS) is required to send, when the time expires 
5 for sending the next service announcement message or service notification 
message of Multimedia Broadcast/Multicast Service (MBMS), proceeding to 
step (6). 

The step of the UE receiving the service announcement message or 
service notification message of Multimedia Broadcast/Multicast Service 
1 0 (MBMS) via cell broadcast further includes the following steps: 

(1) Multimedia Broadcast/Multicast Service Control Module (MBMSC) sends a 
request to BMC with a first primitive for receiving a service announcement 
message or a service notification message of Multimedia Broadcast/Multicast 
Service (MBMS); 

15 (2) If BMC hasn't received any broadcast message before, proceeding to step 
(3); otherwise, proceeding to step (9); 

(3) BMC informs RRC to receive broadcast message with a second primitive, 
which includes the parameters that can inform RRC only to receive a BMC 
preferred message at the prescribed time and to skip some messages; 
20 (4) If RRC has not configured CTCH before, RRC configures link layer (L2) and 
physical layer (LI) to enable UE to receive information on the CTCH and 
feedbacks necessary CTCH configuration information with a third primitive to 
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BMC at the same time, thereafter proceeding to step (5); if RRC has configured 
CTCH resources before, proceeding to step (5) directly; 

(5) According to the requirement of BMC, RRC controls L2 and LI with a 
fourth primitive to receive cell broadcast information on the CTCH at the 

5 prescribed time; 

(6) After processing the data frame received from the CTCH accordingly, LI and 
L2 submit it to BMC in the format of BMC message with a fifth primitive; 

10 (7) BMC analyses the received message, and if it is the service announcement 
message or service notification message of Multimedia Broadcast/Multicast 
Service (MBMS), BMC forwards it to Multimedia Broadcast/Multicast Service 
Control Module (MBMSC) with a sixth primitive, at the same time the reception 
is completed; if it is not the service announcement message or service 

15 notification message of Multimedia Broadcast/Multicast Service (MBMS), 
proceeding to step (8); 

(8) If the message received by BMC is the schedule message, proceeding to step 

(9) ; otherwise, proceeding to step (3); 

20 

(9) BMC analyses the schedule message that was received most recently, and 
checks whether the schedule period described by the schedule message includes 
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the service announcement message or service notification message of 
Multimedia Broadcast/Multicast Service (MBMS) or not. If it is positive, 
proceeding to step (12), otherwise, BMC finds the position of the next schedule 
message and requests RRC to receive the next schedule message with the second 
primitive; 

(10) RRC controls LI and L2 to receive the next schedule message at the 
prescribe time with the fourth primitive; 

(11) After processing the message received from the CTCH accordingly, LI and 
L2 forward the schedule message to BMC with the fifth primitive, and then 
proceeding to step 9); 

(12) BMC finds the position of the Multimedia Broadcast/Multicast Service 
(MBMS) service announcement message or service notification message, and 
requests RRC to receive Multimedia Broadcast/Multicast Service (MBMS) 
service announcement message or service notification message at the prescribed 
time with the second primitive; 

(13) RRC controls LI and L2 to receive the Multimedia Broadcast/Multicast 
Service (MBMS) service announcement message or service notification message 
at the prescribed time with the fourth primitive; 

(14) After processing the message received from the CTCH accordingly, LI and 
L2 forward the Multimedia Broadcast/Multicast Service (MBMS) service 
announcement message or service notification message to BMC with the fifth 
primitive; 
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(15) BMC forwards the Multimedia Broadcast/Multicast Service (MBMS) 
service announcement message or service notification message to Multimedia 
Broadcast/Multicast Service (MBMS) with the third primitive and the reception 
is completed. 

5 

BRIEF DESCRIPTION OF THE DRAWINGS 



The above and other features and advantages of the present invention 
will be more apparent from the following detailed description taken in 
1 0 conjunction with the accompanying drawings, in which: 

Figure 1 illustrates a diagram of logical network apparatuses that can provide 
MBMS service; 

Figure 2 illustrates a flow of MBMS multicast service; 

Figure 3 illustrates a flow of MBMS broadcast service; 
15 Figure 4 illustrates a flow of UE receiving MBMS multicast service data; 

Figure 5 illustrates a flow of UTRAN sending MBMS multicast service data; 

Figure 6 illustrates a flow of UE receiving MBMS broadcast service data; 

Figure 7 illustrates a flow of UTRAN sending MBMS broadcast service data; 

Figure 8 illustrates a message flow of a service announcement process in MBMS 
20 service; 

Figure 9 illustrates a message flow of a data transfer in MBMS service; 

Figure 10 illustrates a functional diagram that explains the process of a service 
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announcement and a service notification in MBMS service; and 
Figure 11 illustrates an example of mapping CTCH onto S-CCPCFL 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

5 

A message flow of a service announcement process in MBMS multicast service. 
In order to explain the process of a service announcement in MBMS service, 
Figure 8 gives a message flowchart of a service announcement process, which 
includes the parts of UE receiving and UTRAN sending. The description is as 
10 follows: 

In Step 801, BMSC requests CBC to send a service announcement in the 
service area of MBMS service through a signaling message. This request may 
include sending times and sending time duration as parameters and the sending 
times can be infinite times. 

15 

In Step 802, CBC commands UTRAN connected with it by a signaling message 
to send the service announcement; according to the requirement of BM_SC, Cell 
Broadcast Center (CBC) may require UTRAN to send the service announcement 
periodically a plurality of times or infinite times. 

20 

In Step 803, UTRAN arranges the time for sending the Multimedia 
Broadcast/Multicast Service (MBMS) service announcement message in proper 
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time of one or more schedule periods according to the requirement of Cell 
Broadcast Center (CBC), adds the brief description information to the schedule 
message that describes each schedule period and sends the schedule message. 
After receiving the schedule message, UE analyses the schedule message and 
5 configures its physical layer to prepare for receiving the Multimedia 
Broadcast/Multicast Service (MBMS) service announcement message. 

In Step 804, UTRAN sends the MBMS service announcement message at 
prescribed time. According to the requirement of CBC, the MBMS service 
10 announcement message may be sent a plurality of times, and therefore steps 803 
and 804 may be repeated a plurality of times without a certain precedence order. 

In Step 805, after the UTRAN completes the sending of the MBMS service 
announcement message, it sends a confirmation message to CBC. 

15 

In Step 806, after receiving the confirmation message from UTRAN, CBC 
returns a confirmation message to BM SC subsequently. 

The flow of a MBMS service announcement is the same as that of a 
20 MBMS broadcast service. 

A transfer process of a MBMS multicast service data including MBMS 
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service notification process. 

The function of MBMS service notification is to inform UE the 
forthcoming MBMS data so that UE can prepare radio resources. Figure 9 is an 
5 example of a MBMS data transfer. The function of the MBMS service 
notification will be explained with reference to the flow of this example: 

In Step 901, the BM_SC initiates an MBMS data transfer and sends 
MBMS data to GGSN. 
1 0 In Step 902, the GGSN sends the data to SGSN by tunneling technique. 

In Step 903, the SGSN informs UTRAN about the forthcoming of the 
MBMS data by a signaling message. 

In Step 904, a Radio data Access Bearer (hereinafter referred to as RAB) 
is established between UTRAN and SGSN. 
15 In Step 905, the SGSN sends MBMS data to UTRAN via RAB. Steps 

905, 906 and 907 are executed without a certain precedence order. 

In Step 906, UMTS Terrestrial Radio Access Network (UTRAN) 
arranges the time for sending the Multimedia Broadcast/Multicast Service 
(MBMS) service notification message, which includes to arrange it in proper 
20 time of one or more schedule periods for sending, to add the brief description 
information to the schedule message that describes each schedule period and to 
send the schedule message; after receiving the schedule message, UE analyses 
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the schedule message and configures its physical layer to prepare for receiving 
the MBMS service notification message. 

In Step 907, UTRAN sends the MBMS service notification message at 
the prescribed time. 

5 In Step 908, UE requests UTRAN to allocate Radio resources (RB) by a 

signaling message. It is possible that there are a plurality of UEs to send requests 
to UTRAN simultaneously at this time. 

In Step 909, UTRAN allocates Radio Bearer (hereinafter referred to as 
RB) according to the number of UEs and other comprehensive factors, and 
10 informs UE. 

In Step 910, UTRAN sends the MBMS data to UE via RB. 

The data transfer flow of MBMS broadcast service is similar with that of 
multicast service, except that it does not need step 908. 

15 

A process of UE receiving a MBMS service announcement message 

For the UE, the process of receiving a MBMS service announcement 
message in multicast service and in broadcast service is the same. This process 
20 will be explained in the following with reference to the functional diagram of 
Figure 10; 

1. When MBMSC (MBMS Service Control module) decides to receive a MBMS 
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service announcement message, MBMSC sends a request to BMC 
(Broadcast/Multicast Control protocol) with primitive P'l; 

2. If BMC has never received any broadcast message before, proceeding to step 
3; otherwise, proceeding to step 9; 

3. BMC informs RRC to receive the broadcast message with primitive C'l. The 
parameters included in C'l may inform RRC to receive RMC preferred message 
only at prescribed time and skip some messages. But in step 3, BMC must 
require RRC to receive all continuous broadcast messages; 

4. If RRC has not configured CTCH before, RRC configures link layer (L2) and 
physical layer (LI) to enable UE to receive information on the CTCH and 
feedbacks necessary CTCH configuration information to BMC with primitive 
C'2 at the same time, then proceeding to step 5; if RRC has configured CTCH 
resources before, proceeding to step 5 directly; 

5. According to the requirement of BMC, RRC controls L2 and LI with 
primitive C'3 to receive Cell Broadcast Information on the CTCH at the 
prescribed time; RRC may control LI to continuously receive CTCH Block Set 
(CTCH BS) or skip some CTCH BSs; 

6. After processing the data frame received from the CTCH accordingly, LI and 
L2 submit it to BMC in the format of BMC message (i.e. BMC PDU) with 
primitive P'3. PDU means Protocol Data Unit, which indicates the message 
format that BMC can identify and create; 

7. BMC analyses the received message. If it is MBMS service announcement 
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message, BMC forwards it with primitive P'2 to MBMSC, at the same time, the 
reception of this time is completed; otherwise, proceeding to step 8; 

8. If the message received by BMC is a schedule message, proceeding to step 9; 
otherwise, proceeding to step 3; 

9. BMC analyses the schedule message that was received most recently, and 
checks whether the schedule period described by the schedule message includes 
the Multimedia Broadcast/Multicast Service (MBMS) service announcement 
message. If so, proceeding to step 12; otherwise, BMC finds the position of the 
next schedule message and requests RRN to receive the next schedule message 
with primitive C'l; 

10. RRC controls LI and L2 with primitive C'3 to receive the next schedule 
message at the prescribed time; 

11. After processing the message received from the CTCH accordingly, LI and 
L2 forward the schedule message to BMC with primitive P'3, then proceeding to 
step 9; 

12. BMC finds the position of MBMS service announcement message, and 
requests RRC with primitive C'l to receive MBMS service announcement 
message at the prescribed time; 

13. RRC controls LI and L2 with primitive C'3 to receive MBMS service 
announcement message at the prescribed time; 

14. After processing the message received from the CTCH accordingly, LI and 
L2 forwards MBMS service announcement message to BMC with primitive P'3; 
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15. BMC forwards the MBMS service announcement message to MBMS with 
primitive P'2 and the reception of this time is completed. 

It is noted that a cell broadcast is transferred through Common Traffic 
5 Channel (CTCH), which is a logical channel and is multiplexed with other 
logical channels into transfer channel FACH together by Medium Access 
Control sublayer MAC. FACH is then multiplexed together with other transfer 
channels into physical channel S-CCPCH by physical layer (PHY). An example 
of CTCH being eventually mapped onto S-CCPCH is shown in Figure 11, in 
10 which CTCH is assigned periodically on the S-CCPCH, and this period is called 
as CTCH Transfer Interval (CTCH TTI). One CTCH BS that includes the whole 
or part content of Cell Broadcast Message can be transferred in a CTCH TTI. 

Schedule period is composed of a group of CTCH BSs (from 1 to 255). 
15 The introduction of schedule period makes CTCH BSs transferred on the CTCH 
is organized into a continuous schedule period. 

A process of UTRAN sending MBMS service announcement message 

20 For UTRAN, the process of sending MBMS service announcement 

message in multicast service and in broadcast service is the same. In addition, 
this process in all cells controlled by the UTRAN is the same also. This process 
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will be explained in the following with reference to the functional diagram of 
Figure 10 by way of one cell as an example: 

1. MBMSC receives a signaling message Ml sent from core network node. Here, 
Ml informs UTRAN to perform the process of MBMS service announcement. 
Ml includes necessary parameters for MBMS service announcement, such as 
times for sending MBMS service announcement and the time interval. The core 
network node that sends Ml signaling message can be SGSN or CBC; 

2. MBMSC requests BMC with primitive PI to send MBMS service 
announcement message. The primitive PI includes necessary parameters for 
constructing MBMS service announcement message; 

3. After receiving the primitive PI, BMC constructs MBMS service 
announcement message and saves it in its own sending memory block, and starts 
up a counter for this message. The initial value of the counter is equal to the 
required times of sending message. If the message is required to send for infinite 
times, the initial value of the counter is assigned with zero or negative value; 

4. BMC estimates transmission rate (hereinafter referred to as Vneed) needed on 
the CTCH according to all messages (including MBMS service announcement 
messages and other broadcast messages) currently saved in the sending memory 
block. If the actual transmission rate (hereinafter referred to as Vetch) on the 
CTCH is 0 (i.e. this cell hasn't allocated CTCH resources) or is much smaller or 
larger than Vneed, BMC reports the actually needed transmission rate Vneed to 
RRC with primitive CI and requests RRC to establish or adjust CTCH resources. 
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During the period of BMC waiting for RRC configuring CTCH resources, if 
Vetch does not match but it isn't equal to zero: when Vetch is smaller than 
Vneed, BMC can still select some messages with high priority and short length 
to transfer; when Vetch is much larger than Vneed, resources on CTCH can 
completely meet the need of message transfer, but it will only result in waste. So 
as described above, BMC still needs to report to RRC; 

5. RRC controls LI and L2 with primitive C3 to establish CTCH or adjust 
CTCH configuration to make CTCH transmission rate match with Vneed. RRC 
informs BMC the new configuration parameters of CTCH with primitive C2. 
What need to be mentioned is that after BMC receives the primitive C2, whether 
CTCH resource adjustment is performed successfully by RRC or not, only if 
Vetch is not equal to zero, BMC will still continue to send broadcast message as 
described in step 4; 

6. BMC adds descriptions for MBMS service announcement message to a 
pending-for-sending schedule message, and then BMC arranges MBMS service 
announcement message on a certain position of the schedule period following 
the schedule message for future sending; 

7. BMC sends the schedule message with primitive P3; 

8. BMC sends MBMS service announcement message at the prescribed time 
with primitive P3; 

9. After reducing the counter's value by one, BMC judges: if the value of the 
counter is negative, it means that MBMS service announcement message is 
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required to send for infinite times, then proceeding to step 10 after adding 1 to 
the value of the counter; if the value of the counter is positive, proceeding to step 
10 directly; if the value is zero, it means that the times of sending MBMS service 
announcement message has reached the requirement, then BMC returns 
5 confirmation information to MBMSC with primitive P2 and the process of 
MBMS service announcement for this time is completed; 
10. BMC waits on-timing according to the time interval that MBMS service 
announcement message is required to send, and when the time expires for 
sending the next MBMS service announcement message, proceeding to step 6. 

10 

A process of UE receiving MBMS service notification message 

For UE, the process of receiving MBMS service notification message in 
multicast service and in broadcast service is the same. This process will be 
15 explained in the following with reference to the functional diagram of Figure 10: 

1. When MBMSC (MBMS Service Control module) decides to receive MBMS 
service notification message, MBMSC sends a request to BMC 
(Broadcast/Multicast Control protocol) with primitive P' 1; 

2. If BMC has never received any broadcast message before, proceeding to step 
20 3; otherwise, proceeding to step 9; 

3. BMC informs RRC to receive the broadcast message with primitive C'l. The 
parameters included in C'l can inform RRC to receive RMC preferred message 
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only at prescribed time and skip some messages. But in step 3, BMC must 
require RRC to receive all continuous broadcast messages; 

4. If RRC has not configured CTCH before, RRC configures link layer 
(hereinafter referred to as LI) and physical layer (hereinafter referred to as LI) 
to enable UE to receive information on the CTCH and feedbacks necessary 
CTCH configuration information with primitive C'2 to BMC at the same time, 
thereafter proceeding to step 5; if RRC has configured CTCH resources before, 
proceeding to step 5 directly; 

5. According to the requirement of BMC, RRC controls L2 and LI with 
primitive C'3 to receive Cell Broadcast Information on the CTCH at the 
prescribed time; RRC can control LI to continuously receive CTCH BS or skip 
some CTCH BSs; 

6. After processing the data frame received from the CTCH accordingly, LI and 
L2 submit it to BMC in the format of BMC message (i.e. BMC PDU) with 
primitive P'3. PDU means Protocol Data Unit, which indicates the message 
format that BMC can identify and create; 

7. BMC analyses the received message. If it is a MBMS service notification 
message, BMC forwards it to MBMSC with primitive P'2, at the same time, the 
reception of this time is completed; otherwise, proceeding to step 8; 

8. If the message received by BMC is a schedule message, proceeding to step 9; 
otherwise, proceeding to step 3; 

9. BMC analyses the schedule message that was received most recently, and 
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checks whether the schedule period described by the schedule message includes 
MBMS service notification message. If so, proceeding to step 12; otherwise, 
BMC finds the position of the next schedule message and requests RRC to 
receive the next schedule message with primitive C'l; 
5 10. RRC controls LI and L2 with primitive C'3 to receive the next schedule 
message at the prescribed time; 

11. After processing the message received from the CTCH accordingly, LI and 
L2 forwards the schedule message to BMC with primitive P'3 and then 
proceeding to step 9; 

10 12. BMC finds the position of the MBMS service notification message and 
requests RRC with primitive C'l to receive MBMS service notification message 
at prescribed time; 

13. RRC controls LI and L2 with primitive C'3 to receive MBMS service 
notification message at the prescribed time; 
15 14. After processing the message received from the CTCH accordingly, LI and 
L2 forward the MBMS service notification message to BMC with primitive P'3; 
and 

15. BMC forwards the MBMS service notification message to MBMSC with 
primitive P'2 and the reception of this time is completed. 

20 

A process of UTRAN sending a MBMS service notification message 
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For UTRAN, the process of sending MBMS service notification 
message in multicast service and in broadcast service is the same. In addition, 
this process in all cells controlled by the UTRAN is the same also. This process 
will be explained in the following with reference to the functional diagram of 
Figure 10 by way of one cell as an example: 

1. MBMSC receives the signaling message M2 sent from core network node. 
Here, M2 informs UTRAN to perform the process of MBMS service notification. 
M2 includes necessary parameters for MBMS service notification, such as times 
for sending MBMS service announcement and the time interval. The core 
network node that sends M2 signaling message can be SGSN or CBC; 

2. MBMSC requests BMC to send MBMS service notification message with 
primitive PI. The primitive PI includes necessary parameters for constructing 
MBMS service notification message; 

3. After receiving the primitive PI, BMC constructs MBMS service notification 
message and saves it in its own sending memory block, and starts up a counter 
for this message. The initial value of the counter is equal to the required times of 
sending message. If the message is required to send for infinite times, the initial 
value of the counter is assigned with zero or negative value; 

4. BMC estimates transmission rate (hereinafter referred to as Vneed) needed on 
the CTCH according to all messages (including MBMS service notification 
messages and other broadcast messages) currently saved in the sending memory 
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block. If the actual transmission rate (hereinafter referred to as Vetch) on the 
CTCH is 0 (i.e. this cell hasn't allocated CTCH resources) or is much smaller or 
larger than Vneed, BMC reports the actually needed transmission rate Vneed to 
RRC with primitive CI and requests RRC to establish or adjust CTCH resources. 

5 During the period of BMC waiting for RRC configuring the CTCH resources, if 
Vetch does not match but it isn't equal to zero: when Vetch is smaller than 
Vneed, BMC can still select some messages with high priority and short length 
to transfer; when Vetch is much larger than Vneed, resources on CTCH can 
completely meet the need of message transfer, but it will only result in waste. So 

1 0 as described in above, BMC still needs to report to RRC; 

5. RRC controls LI and L2 with primitive C3 to establish CTCH or adjust 
CTCH configuration to make CTCH transmission rate match with Vneed. RRC 
informs BMC the new configuration parameters of CTCH with primitive C2. It 
should be noticed that after BMC receives the primitive C2, whether CTCH 

15 resource adjustment performed successfully by RRC or not, only if Vetch is not 
equal to zero, BMC will still continue to send broadcast messages as described 
in step 4; 

6. BMC adds descriptions for MBMS service notification message to a pending- 
for-sending schedule message, and then BMC arranges MBMS service 

20 notification message on a certain position of the schedule period following the 
schedule message for future sending; 

7. BMC sends the schedule message with primitive P3; 
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8- BMC sends MBMS service notification message at the prescribed time with 
primitive P3; 

9. After reducing the counter's value by one, BMC judges: if the value of the 
counter is negative, it means that MBMS service notification message is required 

5 to send for infinite times, then proceeding to step 10 after adding 1 to the value 
of the counter; if the value of the counter is positive, proceeding to step 10 
directly; if the value is zero, it means that the times of sending MBMS service 
notification message has met the requirement, then BMC returns confirmation 
information to MBMSC with primitive P2 and the process of MBMS Service 
10 notification for this time is completed; and 

10. BMC waits on-timing according to the time interval that MBMS service 
notification message is required to send. When the time expires for sending the 
next MBMS service notification message, proceeding to step 6. 

15 Message structures used in the processes of MBMS service announcement and 
MBMS service notification 

♦ Schedule message 

20 A schedule message occupies one or more CTCH BSs included in a 

schedule period. The schedule message describes the schedule period that 
directly follows the schedule message to which the schedule message belongs, 
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which makes continuous schedule messages be able to describe continuous 
schedule periods. Its structure is shown in Table 1 . 



Information Element 
(IE) 


Need 


Plurality 
existence 


Semantics description 


Message Type 


necessary 






Offset to Begin CTCH 

D & index 


necessary 






Length of Scheduling 
Period 


necessary 






New Message Bitmap 


necessary 






Message Description 


necessary 


1 To <the 
length of 
schedule 
period> 


Message description 
includes a plurality of 
items, wherein each item 
describes the message 
content included in one 
CTCH BS of the 
schedule period. The i-th 
item corresponds to the i- 
th bit of new message 
bitmap. 



Table 1 structure of schedule message 

5 

Message Type, the sub-information element in schedule message, is 
included in all the cell broadcast message. It describes the message types, whose 
coding is shown in Table 2. 
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1 


CBS Message 


2 


Schedule Message 


3 


CBS41 Message 




MBMS Ser^ce - 'J^buncement 
Message 


5 


MBMS Service ~~" Notification 
Message : 2 


0, 6...255 


Reserved for future use (PDU with 
any coding herein shall be discarded 
by the protocol of this version.) 



Table 2 Coding of Information Element in Schedule Message 

New message bitmap, the sub-information element in schedule message, 
is a map of bits, each bit of which corresponding to a CTCH BS in the schedule 
5 period. The bit value is 1, which indicates that CTCH BS includes a new 
message, and the bit value is 0, which indicates that CTCH BS includes an old 
message, whose structure is shown in Table 3. 



CTCH 

BS 
Index 

B 


CTCH 

BS 
Index 
B+1 


CTCH 

BS 
Index 

B+2 


• ■ » 










1 


















2 
























CTCH 

BS 
Index 

E-1 


CTCH 

BS 
Index E 


0 


0 


0 


0 


n 



Table 3 structure of new message bitmap of Information Element in 
10 schedule message 

There is a plurality of sub-information element message descriptions in a 
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schedule message, whose number is equal to the number of CTCH BSs included 
in the schedule period described by the schedule message. Each CTCH BS is 
described by one message description, whose structure is shown in Table 4. 



Information 
Element 

(IE) 


Need 


Type 


Semantics 
description 


Message 

Description 

Type 


necessary 


Enumerated value 
(0..255) 
Table 5 




Message ID 


Decision 
condition 
MDT11 


Enumerated value 
(0 2 ,6 -l) 




Offset to 
CTCH BS 
index of first 
transmission 


Decision 
condition 
MDT22 


Integer (0..255) 




service 
Identity ' 


Decision ■ ••. , 
condition 


IFmuhicast address!; 


This Information 

llfMent is usedjfo) :•• •: 
identify the types of 
MBMS service. 


MBMS : 

service 

Identity 


D^feionT ^ 
condition 




This fofomiatipn , 
Element is used to 
identify the types of 
MBMS service. ■ ■ 



5 Table 4 structure of Information Element Message description in schedule 
message 

The types of the message included by CTCH BSs are described by the Sub- 
information Element Message Description Type of Message Description 
10 Information Element, whose coding is shown in Table 5. 
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Values 


Interpretation 


0 


Repetition of new BMC message within schedule period 


1 


New message 


2 


Reading advised 


3 


Reading optional 


4 


Repetition of old BMC message within schedule period 


5 


Old message 


6 


Schedule message 


7 


CBS41 message 








ji^M&s^^ M:m:^)<,r 


10. 255 


Reserved for future use 



Table 5 Coding of the types of Sub-information Element Message 
Description in Message Description Information Element 



5 Since except for Message Description Types, other Sub-information 

Elements do not absolutely exist, their existence is determined by the decision 
conditions. The decision condition for each Sub-information existence is shown 
in Table 6. 
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Decision condition 


Interpretation 


MDT11 


If Message Description Types = 1 or 5, then: 
The Information Element of Message Identity exists. 


MDT22 


If Message Description Types = 0 or 4, then: 
The Information Element of Offset to CTCH BS 
index of first transmission exists and indicates the 
offset of CTCH BS that is the first one including 
broadcast message in this schedule period to schedule 
message. 


MDT33 ; J£ 


K the MeM^ Type§ f 8 (MBMS service 
announcement message) and the message structure in 
Table 8 is selected for use, then: 
•The formation Element ;of MBMS service Identity 
! exists and is identified' by IP multicast address; 




If tbj Message Diescnptipn types', f 9 (NIBMS service 
notification message); then: ^| ^ 
The Information Blement -of to|^|!|emce: Identity 
:<eMs!a|d M6ieM^M^dQi; 



Table 6 Decision Conditions for deciding whether a certain Sub-information 
Elements exist in Information Element Message Description 



♦5 MBMS service announcement message 



MBMS service announcement message describes parameters such as 
MBMS service types and service areas, and may have two kinds of structures: 
the first kind of structure describes a plurality of MBMS services, as shown in 
10 Table 7; and the second kind of structure describes single MBMS service, as 
shown in Table 8. 
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Information Element 
(IE) 


Need 


Semantics description 


Message Type 


necessary 




Service Number 


necessary 


The number of MBMS services 
described in the message 


MBMS service Identity 1 




The Identity of the firat MBMS 
service: IP multicast address 


A PKT 1 
/Vi IN 1 




1 11C UVJlIlalll IlalllC Ul atLCoo 

point, for pointing to one 
GGSN 


UE capability 1 




The capability of UE required 
by the first MBMS service 








MBMS service Identity n 




The Identity of the n-th MBMS 
service, n = Service Number 


APNn 






UE capability n 




The capability of UE required 
by the n-th MBMS service 



Table 7 structure of the first kind of MBMS service announcement message 



Information Element 
(IE) 


Need 


Semantics 
description 


Message Type 


necessary 




MBMS Service Identity 




Identity of this MBMS 
service: IP multicast 
address 


APN 






UE capability 







5 Table 8 structure of the second kind of MBMS service announcement 
message 



-41 - 



Patent Application No. 10/524,715 
Substitute Specification 
Docket: 678-1881 



MBMS Service notification message 



MBMS service notification message is notification information about a 
certain forthcoming MBMS service and informs UE to prepare for the MBMS 
5 service. Its structure is shown in Table 9. 



Information Element 
(IE) 


Need 


Semantics 
description 


Message Type 


necessary 




MBMS Service Group 
Identity 


necessary 


Identity of this MBMS 
service group: TMGI 


QoS 


necessary 


Quality of Service that 
can be provided by 
this MBMS service 


Random Mechanism 


Optional 


Pre-coding random 
mechanism 


Random Value 


Optional 




Mask Value 


Optional 





Table 9 structure of MBMS service notification message 



To avoid air congestion from simultaneous responses to access network 
10 when a plurality of UEs receive MBMS service notification message 
simultaneously, there should be such a mechanism that allows large number of 
UEs to respond at different time. Sub-information Element random mechanism, 
random value and mask value in the MBMS service notification message are all 
set for this. Random mechanism indicates which operation mode to be used by 
15 coding. IMSI of UE (the unique ID of an UE over the world), random value and 
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mask value are participated in operation together and the operation results is 
used as time delay that UE initiates a response with time as the unit (e.g. 
millisecond). Table 10 shows the coding modes of random mechanism. 



0 


After IMSI modulo the random value, performing 
bit-by-bit AND operation with the mask value. 


1 


After IMSI adding to the random value, 
performing bit-by-bit AND operation with the 
mask value. 


2 


After IMSI multiplying with the random value, 
performing bit-by-bit AND operation with the 
mask value. 


3 


After IMSI dividing by the random value, 
performing bit-by-bit AND operation with the 
mask value. 



5 Table 10 coding of random mechanism of Sub-information Element in 
MBM S service notification message 

As noted from the above description, the present invention effectively uses 
the network resources since the processes of MBMS service announcement and 
10 service notification are all performed via cell broadcast, the one-to-multiple 
characteristic of cell broadcast reduces the load of resources resulted from these 
two processes effectively. 

In addition, the present invention effectively reduces standby time of UEs 
since cell broadcast enable UEs to receive cell broadcasts in discontinuous mode, 
1 5 remarkably increasing the lifetime of UEs* batteries; 
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The present invention also improves scalability since cell broadcast uses 
messages of variable length, thereby effectively adding parameters for future use. 
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ABSTRACT 

A method of making use of Cell Broadcast to support MBMS transfer 
service announcement or service notification transfer. The method of transferring 
service announcement includes steps of a CBC commanding a UTRAN 
5 connected with it by a signaling message to send a service announcement; the 
UTRAN arranges the prescribed time of sending the MBMS service 
announcement message, adds the brief description information to the schedule 
message and sends the schedule message; after receiving the schedule message, 
a UE configures a physical layer thereof to prepare for receiving the MBMS 
10 service announcement message. The UTRAN sends MBMS service 
announcement message at the prescribed time. 
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